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ABSTRACT 



A technique for synchronizing databases in which different 
techniques are used for storing a recurring event. A database 
in which the recurring event is, for example, stored as a 
single recurring record can be synchronized with a database 
in which the same recurring event is stored as a series of 
individual records. The individual records are processed to 
form a synthetic recurring record representing the set of 
individual records, and synchronization decisions are based 
on a comparison of the synthetic record to the recurring 
record of the other database. Following synchronization, the 
synthetic record can be "fanned" back into the individual 
records to update the database containing individual records, 
and the updated recurring record can be written back to the 
other database. In this way, the invention avoids the prob- 
lems encountered with prior methods, in which synchroni- 
zation resulted in a recurring record being transformed into 
a series of individual records. 

58 Claims, 41 Drawing Sheets 
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Pseudo Code for Generic A_Sanitization of B DB Records in Workspace 
A_Translator: 



350. REPEAT 

35 1 . FOR EVERY Field in an A_Record 

352. REQUEST Field from Synchronizer 

353. IF LastJField, THEN EXIT LOOP 

354. SANITIZE Field, according to A Sanitization rules 

355. END LOOP 

356. IF Last_Field, THEN EXIT LOOP 

357. SANITIZE Record according to A_Sanitization rule 

358. FOR EVERY Field in an A_Record 

359. SEND Field value to Sanitizer 

360. END FOR 

361. UNTIL EXIT 

SYNCHRONIZER: 

375. In Response to Request for Field by A_Sanitizer 

376. REPEAT UNTIL LAST RECORD 

377. READ B_Record 

378. MAP Record according to B_A Map 

379. REPEAT UNTIL A_Translator Request a field from a new Record 

380. SEND REQUESTED B_field to A Translator 

381 . WATT FOR RETURN of B_Field from AJTranslator 

382. STORE field Value in Mapping Cache 

383. END LOOP 

384. MAP record in Cache according to A-B Map 

385. STORE record in WORKSPACE 

386. END LOOP 

387. SEND Last_Field flag in response to REQUEST 



FIG. 9 
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Current 
Item Outcome 



/ / Original 
// Item 

// 

{ 

//--- TIFCIG_00l - l (0) // item is present in BDB only 



B, 
B, 



B, oLEAVEJOONE, // unloading to BDB 

B, gADD, // unloading to ADB 

oSAVE, // unloading to History File 



B, B, 

//— CIGJ00 - 1 (1) // item is present in ADB only 



A_ A_ oADD, // unloading to BDB 

A_ A_ oLEAVE_ALONE, // unloading to ADB 

A_ A_ ©SAVE, // unloading to History File 

//— CIG_10i - 1 (2) // item is identical in ADB and BDB 

B_ B_ oLEA VE_ ALONE , // unloading to BDB 
A_ A_ oLEAVE_ALONE T // unloading to ADB 
A_ B_ oSAVE, // unloading to History File 

//— CIG_102 - 1 (3) // NEW ADB ITEM < > NEW BDB ITEM 
// (the BDB WINS outcome is shown here) 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ B_ oUPDATE, // unloading to ADB 
A_ B_ oSAVE, // unloading to History File 

//— CIG_1 11-1 (4) // item is unchanged across the board 



B B_ 
A* A 

h" h" 



oLEAVE_ALONE, // unloading to BDB 
oLEAVEALONE, // unloading to ADB 
oSAVE, // unloading to History File 



//— CIG_1 12 - I (5) // item CHANGED in BDB since last sync 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ B_ oUPDATE, // unloading to ADB 
*L B_ oSAVE, // unloading to History File 

//— CIGJ 10 - 1 (6) // item DELETED from BDB since last sync 



H_ H_ 

a" a" 

H~ H" 



oLEAVEDELETED, // unloading to BDB 
oDELETE, // unloading to ADB 
oDISCARD, // unloading to History File 



FIG. 26A 



FIG. 26B 



FIG. 26C 



FIG. 26D 



FIG. 26 



FIG. 26A 
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//— CIG_21 1 - I {1)11 item CHANGED in ADB since last sync 

B_ A_ oUPDATE, // unloading to BDB 

A_ A_ oLEAVEALONE, // unloading to ADB 
H_ A_ oSAVE, // unloading to History File 

//_. CIGJ12 - 1 (8) // item CHANGED IDENTICALLY in Src & BDB 

B_ B_ oLEAVEj\LONE, // unloading to BDB 
A™ A~ oLEAVE* ALONE, // unloading to ADB 
H_ A_ oSAVE, // unloading to History File 

//— CIG_213 - 1 (9) // item CHANGED DIFFERENTLY in Src & BDB 
// (the BDB WINS outcome is shown here) 

B_ B_ oLEAVEALONE, // unloading to BDB 
A_ B_ oUPDATE, // unloading to ADB 
H~ B" oSAVE, // unloading to History File 

//-- CIG_210 -1 (10) // CHANGED in ADB, DELETED from BDB 

A_ A_ oADD, // unloading to BDB 

A A_ oLEAVE_ALONE, // unloading to ADB 

H_ A_ oSAVE, // unloading to History File 

//— CIGJ01 1-1 (11)// item DELETED from ADB since last sync 

oDELETE, // unloading to BDB 
oLEAVEDELETED, // unloading to ADB 
oDISCARD, // unloading to History File 

//— CIGJ012 - 1 (12) // DELETED from ADB, CHANGED in BDB 

oLEAVE_ALONE, // unloading to BDB 
oADD, // unloading to ADB 

oSAVE, // unloading to History File 

//-- CIGJD10 - 1 (13) // item DELETED from both ADB & BDB 

oLEAVE_DELETED, // unloading to BDB 
oLEAVE_DELETED, // unloading to ADB 
oDISCARD, // unloading to History File 



// to a "compromise" value stored in P-item 
// outcome is always UPDATE BOTH 

oUPDATE, // unloading to BDB 

oUPDATE, // unloading to ADB CI/"* OCQ 

oSAVE, // unloading to History File fliJ. ZOD 



B 


B 


H~ 


H 


H~ 


H_ 


'— CIG 


012- 


B 


B 


B~ 


B~ 


H~ 


B~ 


CIG 


010- 


H 


H 


H~ 


H~ 


H~ 


H~ 


— CIG. 


.132- 


B 


H 


A~ 


H 


A_ 


H 
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CIG OF - 1 



(15) // 132 UPDATE-BOTH 
// which has been Fanned To BDB 



B_ B_ oDELETE, // unloading to BDB 
A~ H~ ©UPDATE. // unloading to ADB 
A_ H_ oSAVE // unloading to History File 



// Note that we delete the recurring master on the BDB Side; 
// fanned instances take its place. 



The table entries above for CIGJ02 and CIG_213 are only relevant when the Conflict Resolution Option is set to 
BDB WINS. If the Conflict Resolution Option is set to IGNORE or ADB WINS then those table entries are 
adjusted accordingly. For IGNORE we use the following table entries: 

// Original Current 

// Item Item Outcome 

//— _CIG_TYPEJ02 // NEW ADB ITEM < > NEW BDB ITEM 

B_ B_ oLEAVE_ALONE > // unloading to BDB 
A_ A_ oLEAVE* ALONE, // unloading to ADB 
B_ B_ oDISCARD, // unloading to History File 

//— _CIG_TYPE_2I3 // item CHANGED DIFFERENTLY in Src & BDB 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A_ A_ oLEAVE_ALONE, // unloading to ADB 
H - H _ oSAVE. " // unloading to History File 

And for ADB WINS we use the following table entries: 

// Original Current 

// Item Item Outcome 

//— _CIG_TYPEJ02 // NEW ADB ITEM < > NEW BDB ITEM 

B_ A_ o UPDATE, // unloading to BDB 
A_ A_ oLEAVE_ALONE, // unloading to ADB 
B_ A_ oSAVE, ~ // unloading to History File 

//— _CIG_TYPE_213 // item CHANGED DIFFERENTLY in Src & BDB 

B_ A_ ©UPDATE, // unloading to BDB 
A_ A_ oLEAVEALONE. // unloading to ADB 
H_ A_ oSAVE, // unloading to History File 



When the NOY option is in effect, CIG-spcciflc conflict outcomes are recorded in the CIG members' flag bits. 
When this is the case the following lookup table is used: 

static unsigned char TableAfterlLCR [ SYNC OUTCOME COUNT) 
[AFTER LCR CIG TYPE COUNT] 
[SYNC_UNLOAD_PHASE_COUNT] 



[3] - 



FIG. 26C 
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//Original Current 

// Item Item Outcome 

i 



II Entries for _OUTCOME_SYNC_BDB_WINS 

//— _CIG JTYPEJ02 // NEW ADB ITEM < > NEW BDB ITEM 

B_ B_ oLEAVE_ALONE, // unloading to BDB 
A~ B~ oUPDATE, // unloading to ADB 
A_ B_ oSAVE, // unloading to History File 

//— _CIG_TYPE213 // item CHANGED DIFFERENTLY in Src & BDB 

B_ B_ oLEAVEALONE, // unloading to BDB 
A_ B~ oUPDATE, // unloading to ADB 
H_ B_ oSAVE, // unloading to History File 

// Entries for _OUTCOME_SYNC_ADB_WINS 

//— _CIG_TYPEJ02 // NEW ADB ITEM < > NEW BDB ITEM 

B_ A_ oUPDATE, // unloading to BDB 
A_ A_ oLEAVE_ALONE, // unloading to ADB 
B_ A_ oSAVE, // unloading to History File 

//— _CIG_TYPE_213 // item CHANGED DIFFERENTLY in Src & BDB 

B_ A_ oUPDATE, // unloading to BDB 
A_ A" oLEAVE_ALONE, // unloading to ADB 
H_ A_ oSAVE, // unloading to History File 

// Entries for IGNORE (LEAVE UNRESOLVED) 

//— _CIG_TYPE_102 // NEW ADB ITEM < > NEW BDB ITEM 

B B_ oLEAVE_ALONE, // unloading to BDB 
A~ A_ oLEAVE^ALONE, // unloading to ADB 
B_ B ~ oDISCARD. // unloading to History File 

//— _CIG_TYPE_213 // item CHANGED DIFFERENTLY in Src & BDB 

B_ B_ oLEAVE_ ALONE, // unloading to BDB 
A_ A_ oLEAVE~ ALONE, // unloading to ADB 
H~ H_ oSAVE ~ // unloading to History File 

piG. 26D 
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SYNCHRONIZATION OF RECURRING 
RECORDS IN INCOMPATIBLE DATABASES 

REFERENCE TO MICROFICHE APPENDIX 

An appendix (appearing now in paper format to be 5 
replaced later in microfiche format) forms part of this 
application. The appendix, which includes a source code 
listing relating to an embodiment of the invention, includes 
691 frames on 8 microfiche. 

This patent document (including the microfiche appendix) 30 
contains material that is subject to copyright protection. The 
copyright owner has no objection to the facsimile reproduc- 
tion by anyone of the patent document as it appears in the 
Patent and Trademark Office file or records, but otherwise 

15 

reserves all copyright rights whatsoever. 

BACKGROUND OF THE INVENTION 

This invention relates to synchronizing incompatible 
databases. 20 

Databases are collections of data entries which are 
organized, stored, and manipulated in a manner specified by 
applications known as database managers (hereinafter also 
referred to as "Applications"). The manner in which data- 
base entries are organized in a database is known as the data 2 s 
structure. There are generally two types of database man- 
agers. First are general purpose database managers in which 
the user determines (usually at the outset, but subject to 
future revisions) what the data structure is. These Applica- 
tions often have their own programming language and 30 
provide great flexibility to the user. Second are special 
purpose database managers that are specifically designed to 
create and manage a database having a preset data structure. 
Examples of these special purpose database managers are 
various scheduling, diary, and contact manager Applications 35 
for desktop and handheld computers. Database managers 
organize the information in a database into records, with 
each record made up of fields. Fields and records of a 
database may have many different characteristics depending 
on the database manager's purpose and utility. ^ 

Databases can be said to be incompatible with one another 
when the data structure of one is not the same as the data 
structure of another, even though some of the content of the 
records is substantially the same. For example, one database 
may store names and addresses in the following fields: 45 
FIRST_NAME, LAST_NAME, and ADDRESS. Another 
database may, however, store the same information with the 
following structure: NAME, STREET_NO., STREET_ 
NAME, CITY_STATE, and ZIP. Although the content of 
the records is intended to contain the same kind of 50 
information, the organization of that information is com- 
pletely different. 

It is often the case that users of incompatible databases 
want to be able to synchronize the databases. For example, 
in the context of scheduling and contact manager 55 
Applications, a person might use one Application on the 
desktop computer at work and another on his handheld 
computer or his laptop computer at home. It is desirable for 
many of these users to be able to synchronize the entries on 
one with entries on another. However, the incompatibility of 60 
the two databases creates many problems that need to be 
solved for successful synchronization. The U.S. patent and 
copending patent application of the assignee hereof, Intel- 
liLink Corp., of Nashua, N.H. (U.S. Pat. No. 5,392,390; U.S. 
application, Ser. No. 08/371,194, filed on Jan. 11, 1995, now 65 
U.S. Pat. No. 5,684,990, incorporated by reference herein) 
show two methods for synchronizing incompatible data- 
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bases and solving some of the problems arising from incom- 
patibility of databases. However, other problems remain. 

One kind of incompatibility is when one database man- 
ager uses recurring records. Recurring records are single 
records which contain information which indicates that the 
records actually represent multiple records sharing some 
common information. Many scheduling Applications, for 
example, permit as a single record an event which occurs 
regularly over a period of time. Instances of such entries are 
biweekly committee meetings or weekly staff lunches. Other 
scheduling Applications do not use these types of records. A 
user has to create equivalent entries by creating a separate 
record for each instance of these recurring events. 

Various problems arise when synchronizing these types of 
records. Let us consider a situation when Application A uses 
recurring records while Application B does not. A synchro- 
nizing application must be able to create multiple entries for 
B for each recurring entry in A. It also must be able to 
identify some of the records in database B as instances of 
recurring records in database A. Also, many Applications 
which allow recurring records also permit revision and 
editing of single instances of recurring records without 
affecting the master recurring record. Moreover, single 
instances of a recurring event in Application B may be 
changed or deleted. The recurring master may also be 
changed which has the effect of changing all instances. 
These changes make it harder to identify multiple entries in 
database B as instances of a recurring record in database A. 
Moreover, synchronization must take these changes into 
account when updating records in one or the other database. 

SUMMARY OF THE INVENTION 

The invention provides a technique for synchronizing 
databases in which different techniques are used for storing 
a recurring event. A database in which the recurring event is, 
for example, stored as a single recurring record can be 
synchronized with a database in which the same recurring 
event is stored as a series of individual records. The indi- 
vidual records are processed to form a synthetic recurring 
record representing the set of individual records, and syn- 
chronization decisions are based on a comparison of the 
synthetic record to the recurring record of the other database. 
Following synchronization, the synthetic record can be 
"fanned" back into the individual records to update the 
database containing individual records, and the updated 
recurring record can be written back to the other database. 
In this way, the invention avoids the problems encountered 
with prior methods, in which synchronization resulted in a 
recurring record being transformed into a series of indi- 
vidual records. 

The invention features a computer implemented method 
of synchronizing at least a first and a second database, 
wherein the manner of storing a set of recurring instances 
differs between the first and second databases, and at least 
the first database uses a recurring record to store the set of 
recurring instances. A plurality of instances in the second 
database are processed to generate a synthetic recurring 
record representing recurring instances in the second 
database, the synthetic recurring record of the second data- 
base is compared to a recurring record of the first database, 
and synchronization is completed based on the outcome of 
the comparison. 

Preferred embodiments of the invention may include one 
or more of the following features: Completing synchroni- 
zation may include adding, modifying, or deleting the syn- 
thetic recurring record or the recurring record. Following 
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synchronization, the synthetic recurring record may be 
fanned back into a plurality of single instances. The set of 
recurring instances may be stored in the second database as 
a plurality of single instances. The set of recurring instances 
may be stored in the second database as a recurring record 5 
having a different record structure than the recurring record 
of the first database. A history file may be stored containing 
a record representative of the presence of a recurring record 
or a synthetic recurring record in past synchronizations. 

The invention may be implemented in hardware or 10 
software, or a combination of both. Preferably, the technique 
is implemented in computer programs executing on pro- 
grammable computers that each include a processor, a 
storage medium readable by the processor (including vola- 
tile and non-volatile memory and/or storage elements), at 15 
least one input device, and at least one output device. 
Program code is applied to data entered using the input 
device to perform the functions described above and to 
generate output information. The output information is 
applied to one or more output devices. 20 

Each program is preferably implemented in a high level 
procedural or object oriented programming language to 
communicate with a computer system. However, the pro- 
grams can be implemented in assembly or machine 
language, if desired. In any case, the language may be a 25 
compiled or interpreted language. 

Each such computer program is preferably stored on a 
storage medium or device (e.g., ROM or magnetic diskette) 
that is readable by a general or special purpose program- 3Q 
mable computer for configuring and operating the computer 
when the storage medium or device is read by the computer 
to perform the procedures described in this document. The 
system may also be considered to be implemented as a 
computer-readable storage medium, configured with a com- 35 
puter program, where the storage medium so configured 
causes a computer to operate in a specific and predefined 
manner. 

Other features and advantages of the invention will 
become apparent from the following description of preferred 40 
embodiments, including the drawings, and from the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic drawing of the various modules 
constituting the preferred embodiment. 45 

FIG. 2 is a representation of the Workspace data array. 

FIG. 3 is the pseudocode for the Translation Engine 
Control Module. 

FIG. 4 shows the relationship between 5Q 

FIGS. 4A and 4B; FIGS. 4A and 4B, in combination, are 
the pseudocode for generating the parameter Table. 

FIG. 5 shows the relationship between 

FIGS. 5A and 5B; FIGS. 5A and 5B, in combination, are 
the pseudocode for fanning a recurring record. 55 

FIG. 6 is the pseudocode for the Synchronizer loading the 
History File. 

FIG. 7 is the pseudocode for matching key fields (Key_ 
Field_Match). 

FIG. 8 is the pseudocode for loading records of 
B_Database into Workspace. 

FIG. 9 is the pseudocode for A„Sanitization of 
B_Database records in Workspace. 

FIG. 10 is the Pseudocode for a specific example of a rule 55 
of data value used for sanitization. 

FIG. 11 is the pseudocode for orientation analysis. 
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FIG. 12 is the pseudocode for Conflict Analysis And 
Resolution (CAAR). 

FIG. 13 is the pseudocode for analyzing unique ID 
bearing Fanned Instance Groups (FIGs). 

FIG. 14 is the pseudocode for expanding CIGs created 
from unique ID bearing records. 

FIG. 15 is the pseudocode for finding weak matches for 
a record. 

FIG. 16 shows the relationship between FIGS. 16A and 
16B; 

FIGS. 16A and 16B, in combination, are the pseudocode 
for finding matches between recurring items and non_ 
unique ID bearing instances. 

FIG. 17 is the pseudocode for completing Same Key 
Group (SKG) analysis. 

FIG. 18 is the pseudocode for setting the Maximum 

CIG_Size for every CIG analyzed in FIG. 17. 

FIG. 19 shows the relationship between 

FIGS. 19Aand 19B; FIGS. 19Aand 19B, in combination, 
are the pseudocode for setting CIG_Types. 

FIG. 20 is the User Interface for conflict resolution when 
the Notify option is selected. 

FIG. 21 is the pseudocode for merging exclusion lists. 

FIG. 22 is a look up table used by the function in FIG. 21. 

FIG. 23 is a look up table used by the function in FIG. 21. 

FIG. 24 is a look up table used by the function in FIG. 21. 

FIG. 25 shows the relationship between FIGS. 25 A and 
25B; 

FIGS. 25A and 25B, in combination, are a pseudocode for 
unloading records from Workspace to a non-rebuild-all 
database. 

FIG. 26 shows the relationship between FIGS. 26A, 26B, 
26C, and 26D; 

FIGS. 26A, 26B, 26C, and 26D in combination, illustrate 
the look up table for determining loading outcome results. 

FIG. 27 shows the relationship between FIGS. 27 A and 
27B; 

FIGS. 27A and 27B, in combination, are the pseudocode 
for fanning recurring records of A-Database for unloading. 

FIG. 28 is the pseudocode for unloading the History File. 

FIG. 29 is a table showing cases in which Recurring 
Masters are fanned into own database. 

FIG. 30 is the pseudocode for loading records by a fast 
synchronization Translator. 

FIG. 31 shows the relationship between FIGS. 31 A and 
31B; 

FIGS. 31A and 31B, in combination, are the pseudocoe 
for loading records by a fast synchronization Translator. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

FIG. 1 shows the relationship between the various mod- 
ules of the preferred embodiment. Translation Engine 1 
comprises Control Module 2 and Parameters Table Genera- 
tor 3. Control Module 2 is responsible for controlling the 
synchronizing process by instructing various modules to 
perform specific tasks on the records of the tos&giaiftfeasBs 
b^^^photeoEzed. The steps taken by this module are 
demonstrated in FIG. 3. T he_Parameters Table Generator 3 
is responsible for dBaaAw&a, P arameter_Table 4 whic h is ' 
used by all other modules for synch ronizing the databases. 
Details of the Parameter_Table are described in more detail 
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below. The Synchronizer 15 has primary responsibility for 
carrying out the core synchronizing functions. It is a table - 
driven code which is capable of synchronizing various types 
of databases whose characteristics are provided in the 
Parameter 4 iThe Synchronizer creates and uses the 
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30 



35 



Workspace 16, which is a temporary data array used during 
the synchronization process. 
A Translator 5 (A__Translator) is assigned to the 
^ A_database 13 a nd another Translator 9 (B_Translat or) to 
the 13_ databascHf4. j &ch of thTdatabaseTTranslaTors 5 and 
9 comprises three ^nodules: Reader modules 6 and 10 
(A_Reader and B__Reader), which read the data from the 
databases 13 and 14; Unloader modules 8 and 12 
(A_Unloader and B_Unloader), which analyze and unload 
records from the Workspace into the databases 13 and 14; 
and Sanitizing modules 7 and 11 (A__Sanitizer and 
B_Sanitizer), which analyze the records of the other data- 
base loaded into the Workspace and modify them according 
to rules of data value of its own database. In the preferred 
embodiment, the modules of the A__Translator 5 are 
designed specifically for interacting with the A__database 13 
and the A_Application 17. Their design is specifically based 
on the record and field structures and the rules of data value 
imposed on them by the A_^Application, the Application 
Program Interface (API) requirements and limitations of the 
A^Application and other characteristics of AJ)atabase 
and A_Application. The same is true of the modules of 
B_Translator 9. These Translators are not able to interact 
with any other databases or Applications. They are only 
aware of the characteristics of the database and the Appli- 
cation for which they have been designed. Therefore, in the 
preferred embodiment, when the user chooses two Applica- 
tions for synchronization, the Translation Engine chooses 
the two Translators which are able to interact with those 
Applications. In an alternate embodiment, the translator can 
be designed as a table-driven code, where a general Trans- 
lator is able to interact with a variety of Applications and 
databases based on the parameters supplied by the Transla- 
tion Engine 1. 

Referring to FIGS. 1, 2 and 3, the synchronization process 40 
is as follows. The Parameter__Table 4 is generated by the 
Parameter Table Generator 3. The Synchronizer 15 then 
creates the Workspace 16 data array and loads the History 
File 19 into the Workspace 16. The B_Reader module 11 of 
the B„Translator reads the B_database records and sends 
them to the Synchronizer for writing into the Workspace. 
Following the loading of B_Database records, the 
A_Sanitizer module 8 of the A__Translator 5 sanitizes the 
B__Records in the Workspace. The A_Reader module 7 of 
the A_Translator 5 then reads the A_Database records and 
sends them to the Synchronizer 16 for writing into the 
Workspace. The B_Sanitizer module 12 of the 
B_Translator 9 then sanitizes the A_Records in the Work- 
space. The Synchronizer then performs the Conflict Analysis 
and Resolution (CAAR) on the records in Workspace. At the 55 
end of this analysis the user i s asked whethe r he/she would 

so, the B_Unloader module of the B_JTranslator unloads 
the appropriate records into the B_database. The 
A_Unloader module 6 then performs the same task for the 60 
A_Database. Finally, the Synchronizer creates a new His- 
tory File 19. 

FIG. 3 is the pseudocode for the preferred embodiment of 
the Control Module 2 of the Translation Engine 1. Control 
Module 2 first instructs the Parameter Table Generator 3 of 65 
the Translation Engine 1 to create the Parameter_Table 
(Step 100). FIGS. 4A and 4B are the pseudocode for the 



preferred embodiment of the Parameter Table Generator 
module 3. The user is first asked to choose whether to use a 
previously chosen and stored set of preferences or to enter 
a new set of preferences (Step 150). Steps 151-165 show the 
steps in which the user inputs his/her new preferences. In 
step 152, the user chooses whether to perform a synchroni- 
zation froigjsjHfai^hgQ^ In a 



45 



50 



synchronization from scratch, synchrOflizafion is performed 
as if this was the first time the two databases were being 
synchronized. In an incremental sy "^hrnniz,fltipn, trig His- 
tory File from trie previous file is used to assist with 
synchronization. Th e user will likely choose incrementa l 
synchronization if there_has been a prior synchron ization, 
but the user^mav- choose to synchronize from_s cratclL.wJiere 
the us er would like to start with a clean slate Y perhapsjue 
to significa nt chan g e An the nature of the data in th e 
databases). The user-t hen selects the two_Applications_ and 
rel ated databases ( A_Database and B Jialabajse) to be 
sy n£hronized j[step_15 3). Th e user then chooses (step 154) 
whether the Synchronizer should use the default field map- 
ping for those two databases during synchronization or the 
user will modify the field mapping. Field mapping is gen- 
erally described in U.S. Pat. No. 5,392,390 (incorporated by 
reference). In accordance with the user's preferences, the 
Parameter Table Generator then stores the appropriate 
A^Database to B_Database fields map (A-»B_Map) and 
B__Database to A_Database fields map (B-*A__Map) in the 
Parameter_Tab!e (Steps 155-158 and 159-163, 
accordingly). 

If in step 150 the user selected to use previously chosen 
and stored set of preferences (steps 166-171), those prefer- 
ences are loaded and stored in the Parameter_Table (steps 
169-170). 

In case of date bearing records such as appointments and 
T0D0 lists, the user enters the date range for which the user 
wants the records to be synchronized (step 172). The pre- 
ferred embodiment allows the user to use relative date 
ranges (Automatic_Date_Range) (substeps 171 (a) and 
(6)). For example, the user can select the date range to be 30 
days into the past from today's date and 60 days into the 
future from today's date. The Parameter Table Generator 3 
then calculates and stores in the Parameterjable the Start_ 
Current_Date_Range and End_Current_Date_Range 
values, the two variables indicating the starting point and the 
ending point of the date range for the current synchroniza- 
tion session (step 173-174). 

In steps 174 and 175, various parameters identifying the 
characteristics of the A_Database and Application and 
B_Database and Application are loaded from a database 
(not shown) holding such data for different Applications. 
These are in turn stored in the Parameter_Table. One of the 
sets of parameters loaded and stored in the Parameter_Table 
is the Field_List for the two databases. The Field_List_A 

and Field__List B contain the following information about 

each field in the data structure of the two databases: 

1. Field name. 

2. Field Type. 

3. Field Limitations. 

4. No_Reconcile Flag. 

6. Key_Field Flag. 

7. Mapped_Field Flag. 

Field name is the name given to the field which the Trans- 
lator for this Application uses. This name may also be the 
name used by the Application. Field Type identifies to the 
Synchronizer 15 the nature of the data in a field, e.g., Data, 
Time, Boolean, Text, Number, or Binary. The Field Name 
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does not supply this information to the Synchronizer. Field 
Limitations identifies the various limitations the database 
manager imposes on the contents of a field. These limita- 
tions include: maximum length of text fields, whether the 
text field must be in upper-case, range of permissible values 
(for example, in To Do records priority field, the range of 
permissible values may be limited from 1 to 4), and whether 
a single line or multiple line field. 

No_Reconcile flag indicates whether a field is a 
No_Reconcile field, meaning that it will not be used to 
match records nor will it be synchronized although it will be 
mapped and possibly used in synchronization. Almost all 
fields will not be designated as No_Reconcile. However, 
sometimes it is necessary to do so. Key_Field Mag indicates 
that a field should be considered as a key field by the 
Synchronizer 15. 

Key fields are used by the Synchronizer in various stages 
of synchronization as will be discussed in detail below. The 
decision of identifying certain fields as key is based on 
examining the various Applications to be synchronized, their 
data structure, and the purpose for which the database is 
used. Such examination reveals which fields would best 
function as key fields for synchronization. For example, for 
an address book database, the lastname, firstname, and 
company name field may be chosen as key fields. For 
Appointments, the date field and the description field may be 
chosen as key fields. 

Mapped_Field flag indicates whether a field is mapped at 
all. The Synchronizer uses this flag to determine whether it 
should use the A-»B_Map or B->A_Map to map this field. 
Unlike a No_Reconcile field, an unmapped field will not be 
carried along through the synchronization. 

Another set of parameters in the Parameter__Table iden- 
tify the Translator Modules 13, 14 for the two Applications 
which the user has selected. Because each Application is 
assigned its own Translator, it is necessary to identify to the 
Command Module and the Synchronizer which Translators 
should be used. 

In step 102 of FIG. 1, the Translation Engine instructs the 
Synchronizer to load the History File. History File is the file 
which was saved at the end of last synchronization. It 
contains the history of the previous synchronization which is 
necessary for use with the current synchronization in case of 
Incremental Synchronization. Records from the 
AJDatabase and B_Database are analyzed against the 
records of the history file to determine the changes, 
additions, and deletions in each of two databases since last 
synchronization and whether additions, deletions, or updates 
need to be done to the records of the databases. Referring to 
FIGS. 5A and 5B, in steps 200-201, the Synchronizer finds 
the appropriate History file to be loaded. If 
Synchronization__from_Scratch flag is set, the History File 
is deleted (step 203). If no History File is found, the 
synchronization will proceed as if it was a synchronization 
from scratch (step 204). If the Field Lists stored in the 
History File are not the same as the current Field Lists in the 
Parameter__Table, or the mapping information is not the 
same, the synchronization will proceed as synchronization 
from scratch because the differences indicate that the His- 
tory File records will not properly match the database 
records (steps 206-209). 

In step 210, the Synchronizer uses the Field_List for 
database B to create the Workspace 16. It is a large record 
array which the Synchronizer uses during synchronization. 
Referring to FIG. 2, Workspace 16 consist of two sections. 
First, the Synchronizer uses the Field List for the 
B_Database to make a record array 21 which has all the 
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characteristics of the B„Database record structure. In 
addition, in each record in the Workspace, certain internal 
fields are added. One field is _subtype containing Origin 
Tags. Two other fields, called Rep__Basic and Rep_Excl, 
5 are included for all Appointment and ToDo Sections. The 
Rep_Basic field gives a full description of the recurrence 
pattern of a recurring record. It includes the following 
parameters: 

1. Basic_Repeat_1Vpe 
10 2. Frequency 

3. StopDate 

4. other parameters 

5. Rep_Excl 

Basic_Repeat__Type contains the variable which indi- 
15 cates whether the recurring record is a daily, weekly, 
monthly (same date each month), monthly by position (e.g., 
3rd Friday of each month), yearly (e.g., July 4th each year), 
yearly by Position (e.g., 3rd Friday of September each year), 
quarterly, etc. This variable is set to No_Repeat for non- 
20 recurring records. 

Frequency indicates whether the pattern is, for example, 
for every week, every other week, etc. StartDate and Stop- 
Date show the first date and last date in the pattern. Some 
other parameters in the Rep Jasic include, for example, a 
25 list of days to be included for the pattern (e.g. I plan to hold 
a weekly staff meeting every Thursday starting Nov. 15, 
1997.) 

Rep Excl is the exclusion list. It is a list of dates which 

at some point belonged to the recurring record, but have 

30 since been deleted or modified and no longer are an event 
represented by the recurring record. 

Since some databases do not provide for recurring types 
of records, the synchronization process sometimes must 
create single records for each of the instances of a recurring 

35 record for those databases. For example, for a recurring 
lunch every Thursday, the synchronization must produce a 
single record for each Thursday in such a database. This is 
accomplished by the process of fanning which uses Rep_ 
Basic. Each of those instances is called a fanned instance. 

40 FIG. 6 sets out the preferred embodiment of the process of 
fanning a record. 

Fanning of recurring records also takes into account 
another set of considerations regarding date range limita- 
tions and usefulness of instances to the user. 

45 First, fanning is limited to the applicable date range. 
Second, the number of fanned instances is limited. When 
synchronizing Databases A and B, the preferred embodiment 
permits different sets of limits on fanned instances to be 
established for each Database. This, for example, assists 

50 with managing storage capacity of a memory-constrained 
handheld device when being synchronized with a database 
on a desktop PC. 

If the current Date Range is large enough to accommodate 
more than the maximum number of instances which might 

55 be generated, those instances will be chosen which are likely 
to be most useful to the user. In the preferred embodiment, 
it is assumed that future instances are always more useful 
than past instances, that near future instances are more 
useful than distant future instances, and that recent past 

60 instances are more useful than distant past instances. 
Therefore, based on these assumptions, a fanning date range 
is calculated (FIG. 6, step 236). 

Referring to FIG. 2, in the second step of creating the 
Workspace, the Synchronizer establishes an Extended Index 

65 Array 20 which has an index entry associated with each 
entry in the record array. Each index contains the following 
variables: 
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1. Next_Ia_CIG: 

2. Next_In_SKG: 

3. Next_In_FIG 

4. Key__Field_Hash 

5. A_Unique_ID„Hasb 5 

6. B_Unique_ID_Hash 

7. Non_Key_Field_Hash 

8. Non_Date_Hash 

9. Exclusion__List_Hash 1Q 

10. Start_J)ate&Time 

11. End_Date&Time 

12. Various bit flags 

Next_In_CIG is a linkage word, pointing to next mem- 
ber of the same Corresponding Item Group (CIG). A CIG is is 
a group of records, one from each database and the History 
File, if applicable, which represent the same entry in each of 
the databases and the History File. There may be one, two 
or three records in a CIG. Next_In_SKG is a linkage word, 
pointing to next member of the Same Key Fields Group 20 
(SKG). An SKG is a group of records having the same key 
fields. Next_In_FIG is a linkage word, pointing to the next 
member of the Fanned Instances Group (FIG). A FIG is the 
group of fanned instances which correspond to a single 
recurring record. 25 

Key Jield_Hash is hash of all Key_Fields. A^_unique__ 

ID Hash is hash of unique ID, if any, assigned by 

A_Database. B_unique_ID_Hash is hash of unique ID, if 
any, assigned by B_Database. Non_Key_Field__Hash is 
hash of all Non-Key Match Field, a Match Field being any 30 
mapped field which is not flagged as No_Reconcile. Non„ 
Date_Hash is hash of all Non-Date Non-Key Match Fields. 
Exclusion_List__Hash is hash of recurring record's exclu- 
sion list. 

Start__Date&Time and End_Date&Time are used for 35 
Appointment and ToDo type record only, indicating the start 
and end date and time of the record. They are used to speed 
up comparing functions throughout the synchronization. 
Hash values are also used to speed up the process of 
comparison. The preferred embodiment uses integer hashes. 40 
Hash value computation takes into account certain rules of 
data value for fields, as will be described in more detail 
below. 

In the preferred embodiment, the record array 21 is stored 
on magnetic disk of a computer whereas the Extended Index 45 
20 is held resident in memory. The Extended Indexes have 
record pointer fields which point to each of the records on 
the disk file. 

The Control Module 2 now instructs the synchronizer to 
load the History File into the Workspace (FIG. 3, step 102). 50 
Referring to FIG. 6, the synchronizer loads the records 
beginning in first available spot in the Workspace (step 211). 
The Synchronizer then performs an analysis on each of the 
records and resets some of the values in the records (steps 
212-228). The records are also checked against the current 55 
date range and those falling outside of it are marked appro- 
priately for Fast synchronization function, which will be 
described below. In case of recurring records, if any of the 
instances is within the current date range, then the recurring 
record itself will be considered within the current date range 60 
(steps 217-227). 

The synchronizer then builds SKGs by finding for each 
history record one record which has matching key fields and 
by placing that record in the SKG of the history record (step 
215-216). Referring to FIG. 7, steps 250-258 describe the 65 
Key_Field_Match function used for matching records for 
SKG. 
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When comparing two records or two fields, in the pre- 
ferred embodiment, the COMPARE function is used. The 
COMPARE function is intelligent comparison logic, which 
takes into account some of the differences between the rules 
of data value imposed by the A_^Application and the 
B_Application on their respective databases. Some 
examples are as follows. The COMPARE function is insen- 
sitive to upper and lower case letters if case insensitive field 
attribute is present. Because some Applications require 
entries to be in all capital letter, the COMPARE function 
ignores the differences between upper and lowercase letters. 
The COMPARE function takes into account any text length 
limitations. For example, when comparing "App" in the 
A_Database and "Apple" in the B_Database, the COM- 
PARE function takes into account that this field is limited to 
only 3 characters in the A_Database. It also takes into 
account limits on numerical value. For example, priority 
fields in the A_^Application may be limited to only values up 
to 3, whereas in the B_Application there may not be any 
limitation. The COMPARE function would treat all values in 
B_records above 3 as 3. 

The COMPARE function may ignore various codes such 
as end of line characters. It may strip punctuation from some 
fields such as telephone numbers and trailing white space 
from text fields (i.e "Hello " is treated as "Hello"). It also 
considers field mapping. For example, if the only line that is 
mapped by the A-*B_Map is the first line of a field, then 
only that line is compared. When comparing appointment 
fields, because different databases handle alarm date and 
time differently when Alarmflag is false, the COMPARE 
function treats them as equal even though the values in them 
are not the same. It skips Alarm Date and Time, if the Alarm 
Flag is False. It also ignores exclusion fists when comparing 
recurring records. 

In an alternate embodiment, the COMPARE function may 
take into account more complicated rules for data value of 
the two Applications, such as the rules for data value 
imposed by Microsoft Schedule +, described above. Such a 
COMPARE function may be implemented as a table driven 
code, the table containing the rules imposed by the 
A^Application and the B_Application. Because the COM- 
PARE function has a specific comparison logic and takes 
into account a number of rules, the hashing logic must also 
follow the same rules. It should be noted that the COMPARE 
function is used throughout the preferred embodiment for 
field comparisons. 

Now that the History File is loaded into the Workspace, 
the Control Nodule 2 instructs the B_Translator 13 to load 
the B_Database records (FIG. 3, step 103). Referring to 
FIG. 8, steps 300-308, the B_Reader module 11 of the 
B_Translator 13 loads each B_record which has the right 
Origin Tag, which will be explained in more detail below. 

The record must also be within the loading date range, 
which is a concatenation of the previous and current date 
ranges. The B_Translator sends these records to the Syn- 
chronizer which in turn stores them in the Workspace. When 
synchronizing with a date range limitation, all records which 
fall within either the previous or the current date ranges are 
loaded. The current date range is used during unloading to 
limit the unloading of the records to only those records 
which fall within the database's current date range. In an 
alternate embodiment of the invention, each database or 
Application can have its own date range for each synchro- 
nization. 

Most Applications or databases permit record-specific and 
field-specific updates to a Database. But some Applications 
or databases do not. Instead the Translator for these Appli- 
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cation must re-create the whole database from scratch when 
unloading at the end of synchronization. These databases are 
identified as Rebuild^All databases. To accommodate this 
requirement all records from such a database must be loaded 
into the Workspace, so that they can later be used to rebuild 5 
the whole database. These databases records, which would 
otherwise have been filtered out by the date range or the 
wrong origin tag filters, are instead marked with special flag 
bits as Out_Of_Range or Wrong_Section_Subtype. These 
records will be ignored during the synchronization process 10 
but will be written back unmodified into the database from 
which they came by the responsible Unloader module 6, 10. 

Control Module 2 next instructs the A_Translator 5 to 
sanitize the B-records. Referring to FIG. 9, steps 350-361, 
the A_Sanitizer module 8 of the A_Translator 5 is designed 15 
to take a record having the form of an A_Record and make 
it conform to the specific rules of data value imposed by the 
A_^Application on records of the A_Database. A_Sanitizer 
is not aware which database's field and records it is making 
to conform to its own Application's format. It is only aware 20 
of the A__Application's field and record structure or data 
structure. Therefore, when it requests a field from the 
sanitizer using the A_Database field name, it is asking for 
fields having the A_Database data structure. The 
Synchronizer, in steps 375-387, therefore maps each record 25 
according to the B-»A_Map. In turn, when the Synchro- 
nizer receives the fields from the A_SANITIZER f it waits 
until it assembles a whole record (by keeping the values in 
a cache) and then maps the record back into the B format 
using the A-*-B__Map. 30 

How a record or a field is sanitized in step 354 and 357 
depends on the rules of data value imposed by the 
A_Application. For example, all of the logic of intelligent 
comparison in the COMPARE function described above can 
be implemented by sanitization. However, sanitization is 35 
best suited for more complex or unique types of database 
rules for data value. For example, consider the Schedule+ 
rules regarding alarm bearing Tasks records described 
above. FIG. 10 shows a sanitization method for making 
records of incompatible databases conform to the require- 40 
ments of Schedule +. Without sanitization, when a Tasks 
record of a Schedule+ database is compared to its corre- 
sponding record in another database, the Tasks record may 
be updated in fields which should be blank according to the 
Schedule* rules of data value. Such an update may possibly 45 
affect the proper operation of Schedule+ after synchroniza- 
tion. 

Referring to FIG. 11, following sanitization of all 
B__Records into the Workspace, the Synchronizer sets the 
values for the Extended Index of each record based on the 50 
record's values (steps 451-459). Also if the records in the 
B__Database bear a unique ID, and matches for those unique 
IDs are found in the H_Records in the Workspace, the two 
records are joined in a CIG because they represent the same 
record in both History File and B_Database (step 462). The 55 
record is also joined to an SKG it may belong to (step 464). 
The loading of B_Records is now complete. 

The Control Module 2 of the Translation Engine 3 now 
instructs the A_Translator 5 to load the records from the 
A_Database (step 105). The loading process for the 60 
A_Records is the same as the loading process for the 
B_Database, except for some differences arising from the 
fact that records in the Workspace are stored according to the 
B__Database data structure. Therefore, as the synchronizer 
15 receives each A^_record from the A^_Reader module 7 of 65 
the AJranslator 5, the Synchronizer maps that record using 
the A-»B_Map before writing the record into the next 
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available spot in the Workspace. Since the A__records are 
mapped into the B_Record format, when the B_Sanitizer is 
instructed by the Control Module 2 to begin sanitizing those 
records and starts asking for them from the synchronizer, 
they already have the B_Database format. Therefore, the 
synchronizer 15 does not need to map them before sending 
them to the B_Sanitizer module 12 of the B__Translator 19. 
For the same reason, there is no need for them to be mapped 
once they are sent back by the B_Sanitizer after having been 
sanitized. Once all the records are loaded, the records will 
undergo the same orientation analysis that the B_Records 
underwent (FIG. 11). 

At this point, all records are loaded into the Workspace. 
SKGs are complete since every record at the time of loading 
is connected to the appropriate SKG. CIGs now contain all 
records that could be matched based on unique IDs. At this 
point, the records in the Workspace will be analyzed accord- 
ing to Conflict Analysis and Resolution ("CAAR") which is 
set out in FIG. 12 and in more detail in FIGS. 13-18 and 
corresponding detailed description. 

First, in step 500, ID bearing fanned instances in the 
History File records are matched to the fanned instances in 
the ID bearmg:database^fromiwirteh3they:caine. The records 
from the database which have remained unchanged are 
formed into a new FIG. A new Synthetic Master'isscreated 
based on those records and joined to them. The records 
which have been changed or deleted since last synchroni- 
zation are set free as single records. They also result in a new 
exclusion list being created based on an old exclusion list 
and these new single records. 

Second, in step 501, maieJies:are;sou^t?f^me^IQ : ^ased 
CIGs which are the only CIGs so far created in order to 
increase the membership of those CIGs. Preferably an exact 
all fields match is sought between current members of a CIG 
and a new one. Failing that, a weaker match is sought. 

Third, in step 502, master/instances match is sought 
between reciui^gs^e^^^aOT^nHunique^P bearing 
instances by trying to find the largest group of instances 
which match certain values in the Recurring Master. 

Fourth, in step 503, the items remaining in the SKGs are 
matched up based on either exact all field match or master/ 
instance match, or a weaker match. 

Fifth, in step 501, the appropriate CIG_Types are set for 
all the CIGs. CIG__Types will determine what the outcome 
of unloading the records will be. 

Referring to FIG. 13, first step in CAAR is analyzing 
unique ID bearing Fanned Instance Groups. T his^analvsi s 
atte ffli3teite ^|i mizegttsi ^^ 
in anal^angifan^ 

The analysis is perfbrmed'for all Recurring M23e*fsT(£ie. 
all fe^uSSS^^ewrds) which have ID-bearing fanned 
instances (or FIG records) in the H_File (step 550). All FIG 
records in the History File associated with a Recurring 
Master are analyzed (steps 551-559). They are all removed 
from the SKG. If a FIG record is a singleton CIG , it mean s 
that it was deleted fron^h^datobase ^sjn^i0 aaj^v^^s 
s.^gfeM^i^aj^nw Therefore, iPis adcled to the New_ 
Exclusion_JList (step 553). If a FIG record is a doubleton 
and is an exact match, it means that the record was not 
modified since the previous s^nSSronizaypn. In this case, the 
record from the database is also removed from SKG (step 
555). If a FIG record is a doubleton but is not an exact match 
for its counterpart in the database, it means that the record 
was changed in the database. The History File record is 
treated as a deletion and therefore adde3HfoBtrj£^ ai v_ 
Exclusfo^^ist.<TrieimQQ^ which 
does not match the recurring record any longer, is treated as 
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a free standing record un-associated with the Recurring because this means that there is no possibility of even a weak 

Master (step 557). match for this record (step 619). 

Upon analysis of all FIG records, a new record, the The next step in CAAR is finding non-unique ID bearing 

Synthetic Master, is created and joined in a CI G with the instances for recurring items (FIG. 12, step 503). Referring 

Recurring Master (step 231-236). The Synthetic Master has 5 to FIGS. 16A and 16B, this analysis takes place only if the 

the same characteristics as the Recurring Master, except that database from which instances matching a recurring record 

it has a new exclusion list which is a merger of the are sought does not provide unique ID or if we are syncbro- 

New_Exclusion_JList and the Exchision_List of the Recur- nizing from scratch (steps 65(M>53). The goal of this 

ring Master (step 563). Also a new FIG is created between analysis is to find matching instances for each Recurring 

the Synthetic Master and the CIG-mates of all FIG records 10 Master from a different source than the Recurring Master, 

from the History File (step 565). This analysis counts the number of records in SKG of the 

In steps 567-569, the Synchronizer checks to see if there Recurring Master which have matching Non_JDate_Hash 

are some instances of the Recurring Master which fall within value (steps 665-669). The group of matching SKG records 

the previous synchronization's date range but fall outside of having the same non_Date_Hash value and having the 

the current synchronization's date range. If so, the Fan_ is highest number of members (if the number of members 

Out_Creep flag is set, indicating that the date range has exceeds 30% of unexcluded instances) is then formed into a 

moved in such a way as to require the record to be fanned Homogeneous_Instances_Group (steps 670-672). A Syn- 

for the database before unloading the record. The Fan_ thetic Master is created using the Rep_Basic of the Recur- 

Out__Creep flag is an increase in the value in the Non_ ring Master and using the values from the homogeneous 

Key_Field Hash of the Recurring Master. In this way, the 20 instances group. An Exclusion list is created based on the 

Recurring Master during the unloading of the records will items belonging to the recurrence pattern but missing from 

appear as having been updated since the last synchronization the Homogeneous_Instances_Group. The Synthetic Master 

and therefore will be fanned for the curren tdate range. is added to the CIG of the Recurring Master (steps 

In step 570, all the FIG records an^VyZjed8?^att !a^injffS^ 673-678). A new FIG for the Synthetic Master is then 

analysis ate^nJarked as Dependent_FIGs. This results in 25 created using the Homogeneous_Instances_Group (step 

these records being ignored in future analysis except when 679). These records are removed from any CIGs to which 

the recurring records to which they are attached are being they belonged as weak matches and new weak matches are 

analyzed. sought for those CIGs (steps 680-684). Since the records in 

At the end of the above analysis, all the records having a Homogeneous_Instances_Group have now been matched 

unique ID assigned by their databases have been matched 30 to a recurring record, they are marked as Dependent_FIGs 

based on their uqjqufiflOl* From this point onward, the (step 683). The Recurring Master's CIG is then marked with 

records which do not have unique IDs must be matched to Fan„0ut_Creep flag, if necessary (step 685). 

other records based on their field values. In the preferred The next step in CAAR is completing analysis of records 

embodiment, there are two categories of fie Id value matches: in SKGs (FIG. 12, step 504). Referring to FIG. 17, this 

strong matches and weak matches. A strong match between 35 analysis attempts to increase the population of CIGs up to a 
two records that have matching key fields is when ntSSjggk maximum by finding key field based matches with records 

field&tQi i^eitBft ^ from a source different from those of the CIG records. This 

and^a^ffffflJet^insl^ 606-610). analysis is performed by analyzing all the records in the 

Referring to FIG. 15, a weak match between two records that SKGs except for the singleton SKGs (steps 703 and 712). 

have matching key fields is when the following are true: 40 The first thing is to remove any members that have already 

each of the two records are from different origins, because been marked as WEAK matches attached to ID-based 

two records from the same source should not be in a CIG double ton CIGs. Those are left in the SKG up to this point 

(e.g., ^^^^^g^^^g^^le); each is not a weak to allow for the possibility that a STRONG match would be 

match for another record because there is no reason to prefer found instead. But that is not possible any longer (steps 

one weak match over another; each is not a Dependent_FIG 45 713-715). Once the weak matches have been removed, all 

since these records do not have an independant existence remaining SKG members belong to singleton CIGs. Any 

from their recurring masters; both records are either recur- non-singleton CIGs which are formed from here on will be 

ring or non-recurring since a recurring and a nonrecurring purely key field based. 

should not be matched except if one is an instance of the Throughout the remaining SKG Analysis we are careful 

other in which case it is a strong match; and, in case of 50 not to seek H_Record-A^Record or H_Record-B_Record 

non-recurring, they have matching Key_Date_Field which matches for unique ID-bearing Source, since that would 

is the same as the Start_Date in the preferred embodiment violate the exclusively ID-based matching scheme that 

because items on the same date are more likely to be applies in such cases. Note however that an A_Record-B_ 

modified versions of one another. Record match is acceptable even if both A__Database and 

Referring to FIG. 14, these two types of matching are used 55 B_Database are unique ID-bearing databases, 

to match records to existing CIGs for History File records Given that Key Field should not be performed where ID 

which have been created based on matching unique IDs. based matches are available (or otherwise there may be 

Only doubleton CIGs are looked at, because singleton CIGs matches between records with differing IDs), there are limits 

are handled in step 504 of FIG. 12 and tripleton CIGs are to how big CIGs can get at this point. If both A and 

complete (steps 601-604). If a strong match is found, then 60 B_Databases are unique ID-bearing, any remaining 

if the record was a weak match in another CIG, it is removed H_Record must remain in Singleton CIGs, because they are 

from that CIG, and new weak match is found for that CIG prohibited from forming key fields based matches with items 

(612-614). While weak matches are left in SKGs in case from either databases. Such H_Records are simply removed 

they will find a strong match, strong matches are removed from the SKG when they are encountered. If just one of the 

from their SKGs (step 614). If a strong match is not found, 65 two databases being synchronized is unique ID-bearing then 

then a weak match is sought (steps 617-620). All records in the maximum population that any CIG can now attain is 2 

the CIG are removed from SKG if no weak match is found, (FIG. 18, steps 750—751). If neither database is unique ID 
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bearing then the CIG_Max__Size is three. For every CIG 
which is analyzed in FIG. 17, the CIG_Max_Size is set 
according to this logic. When a CIG reaches its maximum 
possible population all of its members are removed from the 
appropriate SKG. 5 

First, strong matches for the H-records are searched for, 
before trying to find A-B matches. If both Databases are 
non-unique ID-bearing then two strong matches for each 
H_Record, an H*A and an H-B match, are sought (steps 
715-720). If rinding a strong match results in reaching the ao 
CIG__Max_Size, all members of the CIG are removed from 
the SKG (step 721). 

When maximum CIG population is 3, weak matches are 
sought for strong matching CIG doubleton in order to build 
triplet CIGs. The first weakly matching SKG member is 15 
added to the CIG (steps 722-728). Whether or not a weak 
match is found for any of the doubleton CIGs, its members 
are removed from the SKG (step 726). As there are no strong 



default, or the user's case by case decision, must be used to 
determine how the records from the databases should be 
synchronized. CIG types 012 and 210 are cases where a 
previously synchronized record is changed on one side and 
deleted on the other. In the preferred embodiment, such 
conflicts are resolved according to the rule that CHANGE 
overrules the DELETE. So the net result for CIG type 012 
is to add a new record to the A_Database to match the 
record in the B_DATABASE. The reverse is true for CIG 
type 210, where a new record is added to the B_Database. 
In an alternate embodiment, the user may be allowed to 
register an automatic preference for how to resolve such 
conflicts or decide on a case-by-case basis a conflict reso- 
lution option. 

The other two conflict types — 102 and 213 — are resolved 
in the preferred embodiment according to the Conflict 
Resolution Option established by the user. First, the user 
may choose to ignore the conflict. This option leaves all 102 
and 213 conflicts unresolved. Every time synchronization is 
repeated the conflict will be detected again and ignored 



matches left in the SKG, weak matches are found for any 

remaining SKG members and joined to them in CIGs (steps 20 again, as long as this option remains in effect and as long as 

722-725). the conflicting records are not changed by other means. 

At this stage, all CIGs are built. They must now be The user may choose to add a new record to each of the 

examined to determine what needs to be done to these two databases. This option resolves 102 and 213 conflicts by 

records so that the databases are synchronized, i.e. whether adding the new A^Record to the B_Database, and adding 

the records in the CIGs need to be added, deleted or changed 25 the new B_Record to the AJJatabase. This option is 



in the two databases. First step is determining the CIG_ 
TYPE which represents the relation between the records. 
The following CIG types are defined, all using a 3-digit 
number that represents values found for A_DATABASE, 
History File, and B_Database, respectively: 

1. 001— record is "new" in the B_DATABASE 

2. 010 — record is present in History, but absent in both 
A_Database and B_Databases 

3. 100 — record is "new" in the A_Database 

4. 101 — record is "new" in both A^Database and 
B_DATABASE; same in both 

5. 102 — record is "new" in both A^Database and 
B_DATABASE; different in each (conflict) 

6. 110— record deleted from B_DATABASE 

7. 011 — record deleted from A_Database 

8. 012 — record deleted from A_Database and changed on 
B_DATABASE (DEL vs CHANGE conflict) 



implemented by breaking a 102 CIG into two separate CIGs 
(types 100 and 001) and a 213 CIG into three separate CIGs 
(types 100, 010, and 001). Subsequent processing of those 
descendant CIGs causes new records to be added across and 
30 stored in the History File. 

The user may elect that A_Database records should 
always trump or win over B_database records. This option 
is implemented by changing the CIG type to 211 — the 
processing during unloading the records changes the record 
35 value in the B_Database to match the current record value 
in the A_Database. 

The user may elect that B_Database records should 
always trump or win over B_database records. This option 
is implemented by changing the CIG type to 112 — the 
40 processing during unloading the records changes the record 
value in the A^_Database to match the current record value 
in the B_Database. 

The user may choose to be notified in case of any conflict. 
The user is notified via a dialog box 30, shown in FIG. 20, 



9.210— record changed on A_Database and deleted from 45 whenever a CIG type conflict of 102 or 213 arises. The 
B_DATABASE(DEL vs CHANGE conflict) 

10. Ill — record unchanged since previous synchroniza- 
tion 



11. 112 — record changed on B ^DATABASE only since 
previous synchronization 

12. 211 — record changed on A^_Database only since 
previous synchronization 

13. 212 — record changed identically on both since pre- 
vious synchronization 

14. 213 — record changed differently on each since pre- 
vious synchronization (conflict) 

15. 132 — a conflict (102 or 213) was resolved by forming 

a compromise value; Update both 
16. 13F — created when a 132 Update both CIG is Fanned 

into the B_DATABASE 
FIGS. 19A and 19B show the method used for setting all 
except the last two CIG_Types which are set in other 
operations. 

Four of the CIG types assigned above involve conflicts: 
102, 213, 012, and 210. Conflicts are those instances where 
a specific conflict resolution rule chosen by the user or set by 



dialog box shows the record that is involved in the conflict 
31. It also shows the A_Database 32 and B_Database 33 
values for all conflicting fields, in a tabular display, with 
Field Names appearing in the left column 34. A dropdown 
50 list (not shown) in the lower left hand corner of the dialog 
37, offers a total of three choices — add, ignore, and update. 
The use may choose to add new records or ignore the 
conflict. The user may also choose that the A_Record or 

B Record should be used to update the other record. The 

55 user may also decide to create a compromise record by 
choosing values of different fields and then choosing update 
option. In this case, the CIG type is changed to 132, which 
results in an updating both databases with the new record 
compromise record. 
60 When the user has chosen to be notified in case of conflict, 
if the user chooses to ignore conflict or that either the record 
of the A_Database or the B_DATABASE should win, the 
CIG type is left as a conflict CIG type (102 or 213) and a 
separate Conflict Resolution Choice is stored in the FLAGS 
65 word associated with each CIG member. 

The final step in setting CIG_Types is the process for 
dealing with difficulties which arise from exclusion lists. For 
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example, in a triple Recurring Master CIG, suppose the 
History File Recurring Master does not have any excluded 
instances. The A_Record has the following exclusion list: 

12/1/96, 12/8/96 
The B_Record has the following exclusion list: 

1/1/97, 1/8/97, 1/15/97, 1/22/97, 1/29/97 

If comparison of the Recurring Masters includes compar- 
ing exclusion list Field Values, this set of changes would 
cause the Synchronizer to report a CIG type 213 conflict. 

If the Conflict Resolution Option is set to AJDatabase 
record wins, then the outcome prescribed by the Synchro- 
nizer would be for the A_Database to keep its exclusion list 
as is and for the B_J3atabase to make its exclusion list 
match that of the A^JDatabase. 

The result would be to have a lot of duplicate entries in 
both Databases. The A_Database would have five duplicate 
entries in January 97 — that is the five unmodified Recurring 
Master instances, plus the five modified instances added 
across from B_Database to A_Database. The B_Database 
would have five duplicate entries in January 97, since 
synchronization has wiped out the five exclusions that were 
previously recorded in the B_Database exclusion list. 

Two steps are implemented for dealing with this problem. 
First, the COMPARE function does not take into account 
exclusion list differences when comparing recurring records. 
Second, referring to FIG. 21, any new exclusions added on 
to one recurring record will be added to the other record. The 
merging of exclusion lists is done regardless of any updates 
or conflicts, even unresolved conflicts, between the 
A_Database and B_Database copies of a Recurring Master. 
One exception is for CIG type 102 conflict which is left 
unresolved where Exclusion lists are not merged, because 
the user has chosen to leave those records as they are. 

In most cases where it is necessary to merge exclusion 
lists, the CIG types and/or the Conflict Resolution Choice to 
arrange for all necessary updates to be performed during the 
unloading phases of synchronization. 

First, A__Database and B_Database records' exclusion 
lists are compared. In case of databases which do not permit 
recurring items, the exclusion list of the Synthetic Master is 
compared to the recurring record of the other database (step 

852) . If there is no difference, then nothing is done (step 

853) . If there are differences, then it is determined which 
exclusions appear only in one record. This comparison 
always yields one of the following scenarios: (1) all one- 
side-only Exclusions are on the A_Database (so Exclusions 
should be added to the B_Database); (2) all one-side-only 
Exclusions are on the B_Database (so Exclusions should be 
added to the A_Database); and (3) there are one-side-only 
Exclusions on both sides (so Exclusions should be added to 
both databases). 

In each of these cases a separate table is used to look up 
instructions, for how to handle each specific situation (FIGS. 
22-24). The tables cover all possible combinations of pre- 
vious CIG types and outcome codes with all possible 
exclusion list changes (new and different exclusions added 
on A_Database, or on B_Database, or on both sides). FIG. 
22 table is used in case of scenario 1. FIG. 23 table is used 
in case of scenario 2. FIG. 24 table is used in case of scenario 
3 (FIG. 21 steps 854-856). 

The analysis of records is now complete, and the records 
can be unloaded into their respective databases, including 
any additions, updates, or deletions. However, prior to doing 
so, the user is asked to confirm proceeding with unloading 
(FIG. 3, step 108-109). Up to this point, neither of the 
databases nor the History File have been modified. The user 
may obtain through the Translation Engine's User Interface 
various information regarding what will transpire upon 
unloading. 
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If the user chooses to proceed with synchronization and to 
unload, the records are then unloaded in order into the 
B_Database, the A^Database and the History File. The 
Unloader modules 6,10 of the Translators 5,9 perform the 

5 unloading for the databases. The Synchronizer creates the 
History File and unloads the records into it. The Control 
Module 2 of the Translation Engine 1 first instructs the 
B_Translator to unload the records from Workspace into the 
B_Database. Referring to FIGS. 25Aand 25B, for each CIG 
to be unloaded (determined in steps 902-907), based on the 
CIG_TYPE and which database it is unloading into (i.e., A 
or B), the unloader looks up in the table in FIGS. 26A-26D 
the outcome that must be achieved by unloading — that is, 
whether to update, delete, add, or skip (Leave__Alone) (step 
908). In steps 909-913, the unloader enforces date range 

15 restriction for a database subject to date range. The user may 
select, or a selection may be made by default, whether to 
enforce the date range sternly or leniently. In case of stern 
enforcement, all records outside of the current date range 
would be deleted. This is useful for computers with small 

20 storage capacity. In case of lenient enforcement, the records 
are left untouched. 

Based on the result obtained from looking up the unload- 
ing outcome in the table, the unloader then either adds a new 
record (steps 920-926), deletes an existing record (steps 

25 914-919), or updates an existing record (steps 927-933). It 
should be noted that because we only update those fields 
which need to be updated (step 928), the fields which were 
sanitized but need not be updated are not unloaded. 
Therefore, the values in those fields remain in unsanitized 

30 form in the database. 

Referring to step 914, in some Applications when a 
Recurring Master must be added or updated, the record may 
have to be fanned out despite the ability of the Application 
to support recurring records. For example, the Schedule + 

35 Translator is generally able to put almost any Recurring 
Master Item into Schedule* without fanning, but there are 
some exceptions. The Schedule+ Translator uses one Sched- 
ule section to handle all appointments and events. For 
appointments, almost any recurrence pattern is allowed, but 

40 for events the only allowable true repeat type is YEARLY. 
DAILY recurring events can be dealt with by being trans- 
lated into Schedule+ multi-day events which are not recur- 
ring but extend over several days by setting the EndDate 
some time after the Start Date. But for the DAILY case there 

45 are restrictions. In particular exclusions in the midst of a 
multi-day Schedule+ event cannot be created. So the Trans- 
lator decides that if section type is ToDos or the item is a 
non-Event Appointment, then the record need not be fanned 
out. But if item is a YEARLY or DAILY with no exclusions 

50 then it can be stored as a Schedule+ yearly or daily event. 
Otherwise, it must be fanned. 

Referring to FIGS. 27A and 27B, steps 950-984 set out 
the preferred embodiment of fanning recurring records that 
must be updated. All cases fall within three scenarios, shown 

55 in FIG. 29. 

In the first scenario a record which is a Recurring Master, 
and its counterpart in the other database is a Recurring 
Master, must be fanned now for its own database (steps 
951-959). If the CIG_TYPE of the record is 132 (i.e. update 

60 both records), then it is changed to 13F which is a special 
value specifically for this situation (step 951). For other 
CIG_Types, the CIG is broken into three singleton and 
given CIG_Types signifying their singleton status. In both 
of these cases, the function Fanning For_Add (steps 

65 986-996, described below) is called. 

In the second scenario, the record was fanned previously 
and is going to be fanned now also. First, the dates of the 



06/13/2002, EAST Version: 1.03.0002 



19 

instances are recorded in a temporary date array (steps 
961-963). This array is compared to an array of the fanned 
instances of the recurrence pattern of the CIG Recurring 
Master from the other database (steps 965-966). The dates 
which are not in the array of fanned instance are marked for 
deletion (step 967). The dates which are not in the temporary 
date array should be added to the unloading databases and 
therefore new FIG records are created for those dates (steps 
968-973). The dates which appear in both arrays are com- 
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SKG are reset. All the HASH values and 
Start&EndDate&Ume will be stored. All applicable unique 
ID are also stored (Steps 1006-1009). The current record is 
then stored in the new History File (step 1010). If the current 
record is a Recurring Master for an ID-bearing FIG, we now 
store the whole FIG (i.e. all Fanned Instances) in the History 
File, with the FIG linkage words set in the History File to 
hold the FIG records together (step 1011). Fanned instances 
which do not bear unique IDs are not stored in the History 



pared to the Synthetic Master and marked accordingly for 10 File since they can be re-generated by merely fanning out the 



UPDATE or Leave^\lone (steps 974-978). 

In the third scenario, the record which was previously 
fanned should now be fanned also. The opposing database's 
record in this scenario is also fanned instances. This is 
perhaps the most peculiar of the three cases. For example, a 
database may be able to handle multi-day (i.e. daily 
recurring) records but not any exclusion dates for such 
items. Such database may be synchronized with another 
database which fans all records in the following manner. A 



Recurring Master. 

Once all records are unloaded, various information nec- 
essary for identifying this History File and for the next 
synchronization are written into the History File (step 1013). 
is At this point Synchronization is complete. 

Applications, such as scheduling Applications, often have 
more than one database. Each of these databases are known 
as sections. Each of these sections contain different data and 
must be synchronized with their corresponding sections in 



record representing a 7-day vacation in the Planner section 20 other Applications. However, there is not necessarily a one 



of the database is fanned out to form 7 individual vacation 
days in the other database. One instance is deleted in the 
other database. Upon synchronizing the two databases, b/c 
the first databases does not does not provide for exclusion 
lists, the record must now be fanned. 

In this scenario, Master Records in a CIG are marked as 
Garbage. Any FIG members attached to the H_Record, if 
any, are also marked as Garbage. All Instances found in the 
opposing database's FIG are tmned to singleton CIGs with 



to one relationship between sections of various Applications. 
For example, Application A may comprise of the following 
sections: Appointments, Holidays, Business Addresses, Per- 
sonal Addresses, and ToDo. Application B however may 
25 comprise of the following sections: Appointments, 
Addresses, ToDo-Tasks, and ToDo -Calls. Although the gen- 
eral character of the sections are the same, there is not a one 
to one relation between the sections of these two Applica- 
tions: Appointments and Holidays in A contain the same 



CIG type 100 or 001 so that they will be added to the 30 type of data as Appointments in B; Business Addresses and 

unloader's database when unloading is done. In this way the Personal Addresses in A contain the same type of data as 

instances from one database is copied to the database Addresses in B; and ToDo in A contains the same type of 

providing for recurring records. data as ToDo-Tasks and To Do-Calls in B. Therefore, when 

Steps 985-995 describe the Fanning_For_Add Function synchronizing the sections of these two Applications, it is 

which is used when outcome is to update or when the 35 necessary to synchronize at least two sections of one Appli- 

function is called by the Translator fanning for update. For cation with one section of another Application, 

each instance generated by fanning out the recurring record, The preferred embodiment performs this type of synchro- 

a clone of the Recurring Master is created but excluding nization by providing for a number of section categories: 

Rep_Basic and Rep_Excl field values and the unique ID Appointment, ToDo, Note, Address, and General Database, 

field. All adjustable Date Fields (e.g. Start Date, End Date, 40 All sections of a particular Application are studied and 



and Alarm Date) are set and hash values for the new record 
is computed. The new record is then marked as Fanned_ 
For_A or Fanned_For_B, as the case may be. This is then 
attached to the Recurring Master Item as a FIG member. 

Following unloading of the B_RECORDS, the Control 
Module 2 instructs the A__Translator to unload the 
A_Records from the Workspace (FIG. 3, step 111). This 
unloading is done in the same way as it was done by the 
B_Translator. In case of Rebuild_All Translators which 
have to reconstruct the database, all records which were 
loaded from the database but were not used in synchroni- 
zation are appended and unloaded as the Translator builds a 
new database for its Application. 

The Control Module 3 next instructs the Synchronizer to 



45 



50 



categorized according to this categorization. Therefore, in 
the above example of Application A, Appointments and 
Holidays are categorized Appointment type sections (or 
database), Business Address and Personal Address as 
Address type sections, and ToDo as a ToDo type section. 

For creating the map for mapping sections onto each 
other, an exact section match is always sought between 
sections of the two Applications. If not, one of the sections 
which were categorized as a section type is chosen to be the 
Main_Section among them. Other sections of the same type 
are referred to as subsections. All databases of the same type 
from the other Application will be mapped onto the Main_ 
Section. 

To properly synchronize from one time to the next, it is 



create a new History File (step 112). Referring to FIG. 28, 55 necessary to keep track of the source of records in the 

for every CIG in the Workspace, it is first determined which Main_Section. In the preferred embodiment, if a record in 

record should be unloaded to History File (steps the Main_Section of the A_Application does not come 

1001-1003). In the next step, Excl_Only flag is checked, from the Main_Section of the B_Application, one of fields 

which is set by the Merge_Exclusion_List logic (FIG. in the record, preferably a text field, is tagged with a unique 

21-24). If that flag is set, a new record for unloading is 60 code identifying the subsection which is the source of the 

created which has all fields taken from the History File record. This is the record's Origin Tag. All records in the 

record, except that the newly merged exclusion list is Workspace and the History File include a hidden internal 

inserted into that record (step 1004). Before storing the field called_subType which contains the unique subsection 

record in the History File, all Flag Bits in the Extended Index code. Main_Section's field value in the preferred embodi- 

are cleared except the bit that indicating whether or not this 65 ment is zero so that it will not be tagged. When a record is 

is a recurring item (step 1005). The item is marked as a loaded from a database into the Synchronization Workspace, 

History File record to indicate its source. The CIG, FIG, and the tag is stripped from the TagBearer field and put in the 
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_subType field. If there is no tag, then the _subType is set 
to be the subtype of the present section. If the TagBearer 
field is mapped then when reading records into the Work- 
space the tag, if any, is stripped from the TagBearer field 
value place it in _subtype. 

Conversely when unloading records from the Workspace 
to a Database, the TagBearer field is tagged by a tag being 
added if the record is not from the Main__Section. 

A Fast Synchronization database is a database which 
provides a method of keeping track of changes, deletions, 
and additions to its records from one synchronization to the 
next. These databases speed up the synchronization process 
because only those records which have been modified need 
to be loaded from the database. Since the majority of records 
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chronization needs to transform lack of output by the Fast 
Synchronization Translator into unchanged records. 

The invention performs these transformations by using 
the History File. During the first synchronization, all records 
in the Fast Synchronization database are loaded into the 
history file. As changes, additions, and deletions are made to 
the Fast Synchronization database, during each of the sub- 
sequent synchronizations the same change, additions, and 
deletions are made to the History File. Therefore, the History 
File at the end of each subsequent synchronization is an 
exact copy of the Fast Synchronization database. 
When a Fast Synchronization Translator supplies no input 

for a unique ID H Record, the Synchronizer finds the 

corresponding H_Record in the Workspace and copies it 
into the Workspace as a record supplied as if it were loaded 



loaded by regular Translators are unchanged records, far 15 by the Fast Synchronization translator itself, 

fewer records are loaded from the database into the Syn- Referring to FIG. 30, steps 1050-1051, the Synchronizer 

chronizer. first verifies that there is an appropriate History File. 

Certain features are required for a database to be a Fast Because the Fast Synchronizing process relies heavily on the 

Synchronization database. The database records must have History File, it is important to ensure that the same history 

unique IDs and must have a mechanism for keeping track of 20 file as the last Synchronization is used. Moreover, the 



which records are added, changed, or deleted from synchro- 
nization to synchronization, including a list of deleted 
records. Unique IDs are required to accurately identify 
records over a period of time. 

There are at least two ways to keep track of additions, 
changes, and deletions in a database. 

First, some databases maintain one Dirty bit per record 
which is a boolean flag that is set when a record is created 
or modified and is cleared when a function for clearing Dirty 



History File is the background against which the transfor- 
mation of the Translator outputs into regular Translator 
outputs takes place. The History File keeps a date and time 
stamp of the last synchronization. Each of the Fast Synchro- 
25 nization database (if able to) and the Fast Synchronization 
Translator also stores the same date and time stamp. The 
time and date stamp is used because it is unlikely that 
another History File will have exactly the same time and 
date entry, for the same two databases. It also identifies when 



bits is called. Some databases offer a Clear DirtyBit function 30 last the Fast Synchronizer database and the History File 
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that clears the bit of an individual record. Other databases 
offer a ClearDirtyBits function that clears the Dirty bits of all 
records in a database. The record-specific ClearDirtyBit 
function allows the preferred embodiment to use the data- 
base itself to keep track of additions and changes. 

The global ClearDirtyBits function forces the preferred 
embodiment to clear all Dirty bits at the conclusion of every 
Synchronization. Then as database edits are made by the 
user in between synchronizations, the affected records are 
marked as Dirty. When Synchronization is performed again, 40 
only the Dirty records are loaded. 

Second, some databases maintain a Date&Time stamp of 
when the record was added or last time the record was 
modified. A Translator for such a database finds all records 
which were added or modified since the previous synchro- 
nization by searching for Date&Time stamps more recent 
than the Date&Time of the Last Synchronization. 

A Fast Synchronization database must also keep track of 
deletions. This is done by maintaining a list of deleted 
records which can be read by a Translator. 

A Translator sending Fast Synchronization database 
records to the Synchronizer provides only records which 
have been changed, deleted, and added since the previous 
synchronization. Therefore, unlike a regular database 
Translator, a Fast Synchronization Translator does not pro- 
vide the Synchronizer with unchanged records. Moreover, 
unlike a regular Translator it provides deleted records, which 
the regular Translators does not. 

In order for such databases to be synchronized without 
resorting to treating them as regular databases, the Synchro- 
nizer transforms Fast Synchronization records from the 
Translator into the equivalent regular database records. 
These transformed records are then used by the Synchro- 
nizer in the synchronization. There are two transformations 
which are necessary. First, the Synchronizer needs to trans- 
form deleted records received from the Fast Synchronization 
Translator into a regular database deletions. Second, syn- 



contained the same records. 

At the start of an incremental synchronization, the Syn- 
chronizer and the Fast Synchronization Translator compare 
date and time stamps. If time and date stamp synchroniza- 
tion parameters have changed since the previous 
synchronization, then the synchronization proceeds from 
scratch (step 1052). In a synchronization from scratch all 
records in the Fast Synchronization database are loaded into 
the History File. 

In the preferred embodiment, all records supplied as Fast 
synchronization inputs have a special hidden field called 
_Delta, which carries a single-letter value — 'D* for Delete 
or * A* for Add and ' C* for Change. Records are loaded by the 
Fast Synchronization Translator into the Workspace (step 
1054). If necessary the records are mapped when loaded. 
Records which are marked as changes or additions are 
sanitized by the Translator for the other database, but deleted 
records are not because their field values are going to be 
deleted (step 1055). Orientation analysis (FIG. 11) is per- 
50 formed on the records so that all deletions and changes to 
Fast Synchronization database records are joined with their 
History File counterparts in unique ID bearing CIGs (step 
1107). 

All History File records and their CIGs are now exam- 
55 ined. If there is no corresponding record from the Fast 
synchronization database, it means that the record was 
unchanged. A clone of the record is made, labelled as being 
from Fast Synchronization database, and joined to the 
H_Record's CIG. At this point the deleted Fast synchroni- 
60 zation database records marked as deletions are removed 
from CIGs (step 1109). The Fast Synchronization records 
marked as changed are joined in doubleton CIGs. Those 
marked as additions are singletons. At this point, the syn- 
chronization can proceed as if record of a unique ID bearing 
65 regular database were just loaded into the Workspace. 

Whenever we are loading from a Fast Synchronization 
database, all records are loaded so that at the end of 
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synchronization the history file will be the same as the Fast 
Synchronization Database. Therefore, referring to FIGS, 
31A and 3 IB, in order to perform date range limited 
synchronization, the invention marks the records which fall 
outside the current and the previous date ranges. For a record 
marked as an addition, or during synchronizing from 
scratch, if the record falls outside the current date range, it 
is marked as Out__Of_Range (steps 1101 and 1153-1154). 
This record will be written into the History File but not into 
the other database or take part in the synchronization. When 
the Fast Synchronization database records are loaded from 
the History File, if they fall outside of the previous date 
range, they are marked as Bystander (steps 1152-1157). If a 
Bystander record forms a CIG with a Fast Synchronization 
record marked as a deletion or a change, the Bystander is 
marked with a Garbage flag because its field values serve no 
useful purpose any more: the record marked as DELETION 
should be deleted and the record marked as CHANGED 
should replace the Bystander H Record (step 1162). 

H Records for which there are no inputs are transformed 

in the same manner as before (steps 1164-1165). If a 
Bystander record falls within the current date range, it is 
equivalent to a regular database record coming into the 
current date range. Therefore, the H_Record is cloned and 
marked as a Fast Synchronizer record while the Bystander 
record is marked as Garbage (steps 1166-1171). Therefore, 
just like a new record of a regular database, it has no 
H_Record counterpart. 

If the user selects to abort a synchronization or selects the 
option to ignore a conflict or conflicts in general, some of the 
records loaded from the Fast Synchronization database will 
not be accepted and recorded in the History File. Therefore, 
the Translator should provide that record again at the next 
synchronization. However, because Fast Synchronization 
Translators supply only records which have been changed, 
deleted, or added since the previous synchronization, the 
records which were not accepted will not be supplied. 
Therefore, in the invention, Fast Synchronization Translator 
waits for an acknowledgement from the Synchronizer that 
the record has been accepted. 

In case no such acknowledgement is received for a record, 
the Translator needs to be able to provide that record again 
to the Synchronizer. If the database allows resetting indi- 
vidual Dirty bits, the Translator merely does not set that bit. 
If not, the Translator keeps a separate file in which it keeps 
a record of which Fast Synchronization records were not 
accepted. The file may contain the unique IDs of those 
records. The Translator then uses that file to provide the 
synchronizer with those records during the next synchroni- 
zation. 

Other embodiments are within the following claims. 
I claim: 

1. A computer implemented method of synchronizing at 
least a first and a second database, wherein the manner of 
storing a set of recurring date bearing instances differs 
between the first and second databases, and at least the first 
database uses a recurring record to store the set of recurring 
date bearing instances, the method comprising: 

processing a plurality of non-recurring records in the 
second database to identify a set of non-recurring 
records storing a set of recurring date bearing instances 
in the second database; 
performing a comparison of the set of non-recurring 
records of the first database to a recurring record of the 
first database; and 
completing synchronization based on the outcome of the 
comparison. 
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2. The method of claim 1 wherein the step of completing 
synchronization includes adding, modifying, or deleting one 
of the synthetic recurring record and recurring record. 

3. The method of claim 1 further comprising, after com- 
5 pleting synchronization, storing the set of recurring date 

bearing instances in the second database as a plurality of 
non-recurring records. 

4. The method of claim 1 further comprising, after com- 
pleting synchronization, storing the set of recurring date 

10 bearing instances in the second database as a recurring 
record having a different record structure than the recurring 
record of the first database. 

5. The method of claim 1 further comprising storing a 
history file containing a record representative of one of the 

15 recurring record and the set of non-recurring instances in a 
past synchronization. 

6. The method of claim 5 further comprises performing a 
second comparison of one of the synthetic recurring record 
and the recurring record to the record representative of the 

20 recurring record or the set of non-recurring instances and 
completing synchronization based on the outcome of the 
second comparison. 

7. The method of claim 1 wherein each recurring record 
and each non-recurring record includes a key field, and 

25 wherein the step of processing a plurality of non-recurring 
records in the second database further comprises: 
performing a second comparison of the key fields of the 

recurring and non-recurring records; and 
selecting a group of records from among the recurring and 
non-recurring records based on the outcome of the 
comparison. 

8. The method of claim 7 wherein the step of selecting a 
group of records comprises selecting the group based on 
identity of the content of the key fields of the recurring and 
non-recurring records. 

9. The method of claim 7 wherein each recurring record 
and each non-recurring record includes at least one other 
field, and wherein the step of processing a plurality of 
non-recurring records in the second database further com- 
prises: 

performing a third comparison of the at least one other 

field of the non-recurring records in the group; 
selecting a set of non-recurring records based on the 

outcome of the third comparison; and 
correlating the set of non-recurring records to the recur- 
ring record of the first database. 

10. The method of claim 9 wherein selecting the set of 
non-recurring records based on the outcome of the third 

50 comparison is based on identity of content of the at least one 
other field of the non-recurring records in the group. 

11. The method of claim 1 wherein processing the plu- 
rality of non-recurring records further includes processing 
the plurality of non-recurring records to generate a synthetic 

55 recurring record representing the set of recurring date bear- 
ing instances in the second database, and 
wherein performing a comparison of the set of non- 
recurring records to a recurring record includes per- 
forming a comparison of the synthetic recurring record 
60 of the second database to the recurring record of the 
first database. 

12. The method of claim 11 wherein, following the step of 
completing synchronization, one of the synthetic recurring 
record and recurring record is fanned back into a plurality of 

65 fanned non-recurring records. 

13. The method of claim 11 wherein the synthetic recur- 
ring record has a list of excluded instances and the step of 
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processing a plurality of non-recurring records in the second 
database to generate a synthetic recurring record further 
comprises generating a list of excluded instances represen- 
tative of instances previously represented by the recurring 
record and currently represented by another record or 5 
deleted. 

14. The method of claim 11 wherein the recurring record 
and the synthetic recurring record each contain a list of 
excluded date bearing instances, wherein the step of per- 
forming a comparison of the synthetic recurring record to 10 
the recurring record includes performing a comparison of 
the list of excluded date bearing instances of the recurring 
record with the list of excluded date bearing instances of the 
synthetic recurring record. 

15. The method of claim 14 wherein the step of complet- is 
ing synchronization includes adding, modifying, or deleting 
the list of excluded date bearing instances of one of the 
recurring record and the synthetic recurring record. 

16. The method of claim 14 wherein the step of complet- 
ing synchronization includes adding, modifying, or deleting 20 
one of the synthetic recurring record and recurring record. 

17. The method of claim 14 wherein, following the step 
of completing synchronization, one of the synthetic recur- 
ring record and recurring record is fanned into a plurality of 
fanned non-recurring records excluding the instances in the 25 
list of excluded date bearing instances of a corresponding 
one of the synthetic recurring record and recurring record. 

18. The method of claim 11 further comprising storing a 
history file containing a record representative of one of the 
recurring record and synthetic recurring record in a past 30 
synchronization. 

19. The method of claim 18 wherein the second database 
assigns a unique ID to each record, and wherein the method 
further comprises: 

fanning one of the synthetic recurring record and the 35 
recurring record into a plurality of fanned non- 
recurring records; 

storing records in the history file representative of the 
plurality of fanned non-recurring records; 

40 

storing in the history file the unique IDs assigned by the 
second database to the plurality of fanned non- 
recurring records; and 

recording linkages among the records representative of 
the plurality of non-recurring records and the record 45 
representative of one of the recurring record and syn- 
thetic recuning record. 

20. The method of claim 18 wherein the second database 
assigns unique IDs to each record, the history file further 
contains records representative of non-recurring records of 50 
the second database from a past synchronization and unique 
IDs assigned to the non-recurring records of the second 
database, and the step of processing a plurality of non- 
recurring records in the second database to generate a 
synthetic recurring record further comprises: 55 

performing a comparison of the unique IDs stored in the 
history file with unique IDs of the plurality of non- 
recurring records in the second database; and 

selecting a set of non-recurring records in the second 
database based on the comparison of the unique IDs 60 
and generating the synthetic recurring record using the 
set of non-recurring records. 

21. The method of claim 20 wherein the step of selecting 
a set of non-recurring records further comprises selecting a 
set of non-recurring records in the second database having 65 
unique IDs matching a set of the unique IDs stored in the 
history file. 
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22. The method of claim 20 wherein one of the synthetic 
recurring record and the recurring record has an exclusion 
list and the step of selecting the set of non-recurring records 
comprises: 

selecting a set of records in the history file having unique 
IDs failing to match any of the unique IDs of non- 
recurring records in the second database; and 

adding, modifying, or deleting the exclusion list of at least 
one of the synthetic recurring record and the recurring 
record, using the set of records in the history file. 

23. The method of claim 18 further comprises performing 
a second comparison of one of the synthetic recurring record 
and the recurring record to the history file record represen- 
tative of the recurring record or the synthetic recurring 
record in the past synchronization, and completing synchro- 
nization based on the outcome of the second comparison. 

24. A computer program, resident on a computer readable 
medium, for synchronizing at least a first and a second 
database, wherein the manner of storing a set of recurring 
date bearing instances differs between the first and second 
databases, and at least the first database uses a recurring 
record to store the set of recurring date bearing instances, 
comprising instructions for: 

processing a plurality of non-recurring records in the 
second database to identify a set of non-recurring 
records storing the set of recurring date bearing 
instances in the second database; 

performing a comparison of the set of non-recurring 
records of the first database to a recurring record of the 
first database; and 

completing synchronization based on the outcome of the 
comparison. 

25. The computer program of claim 24 wherein the 
instruction for completing synchronization includes adding, 
modifying, or deleting one of the synthetic recurring record 
and recuning record. 

26. The computer program of claim 24 further comprising 
instructions for, after completing synchronization, storing 
the set of recurring date bearing instances in the second 
database as a plurality of non-recurring records. 

27. The computer program of claim 24 further comprising 
instructions for, after completing synchronization, storing 
the set of recurring date bearing instances in the second 
database as a recurring record having a different record 
structure than the recurring record of the first database. 

28. The computer program of claim 24 further comprising 
instructions for storing a history file containing a record 
representative of one of the recurring record and the set of 
non-recurring instances in a past synchronization. 

29. The computer program of claim 28 further comprises 
instructions for performing a second comparison of one of 
the synthetic recurring record and the recurring record to the 
record representative of the recurring record or the set of 
non-recurring instances and completing synchronization 
based on the outcome of the second comparison. 

30. The computer program of claim 24 wherein each 
recurring record and each non-recurring record includes a 
key field, and wherein the instruction for processing a 
plurality of non-recurring records in the second database 
further comprises instructions for: 

performing a second comparison of the key fields of the 
recurring and non-recurring records; and 

selecting a group of records from among the recurring and 
non-recurring records based on the outcome of the 
comparison. 

31. The computer program of claim 30 wherein the 
instruction for selecting a group of records comprises 
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instructions for selecting the group based on identity of the 
content of the key fields of the recurring and non-recurring 
records. 

32. The computer program of claim 30 wherein each 
recurring record and each non-recurring record includes at 5 
least one other field, and wherein the instruction for pro- 
cessing a plurality of non-recurring records in the second 
database further comprises instruction for: 

performing a third comparison of the at least one other 
field of the non-recurring records in the group; aQ 

selecting a set of non-recurring records based on the 
outcome of the third comparison; and 

correlating the set of non-recurring records to the recur- 
ring record of the first database. 

33. The computer program of claim 32 wherein selecting J5 
the set of non-recurring records based on the outcome of the 
third comparison is based on identity of content of the at 
least one other field of the non-recurring records in the 
group. 

34. The computer program of claim 24 wherein process- 
ing the plurality of non-recurring records further includes 20 
processing the plurality of non-recurring records to generate 

a synthetic recurring record representing the set of recurring 
date bearing instances in the second database, and 

wherein performing a comparison of the set of non- 
recurring records to a recurring record includes per- 25 
forming a comparison of the synthetic recurring record 
of the second database to the recurring record of the 
first database. 

35. The computer program of claim 34 wherein, following 
the instruction for completing synchronization, one of the 30 
synthetic recurring record and recurring record is fanned 
back into a plurality of fanned non-recurring records. 

36. The computer program of claim 34 wherein the 
synthetic recurring record has a list of excluded instances 
and the instruction for processing a plurality of non- 35 
recurring records in the second database to generate a 
synthetic recurring record further comprises instructions for 
generating a list of excluded instances representative of 
instances previously represented by the recurring record and 
currently represented by another record or deleted. 40 

37. The computer program of claim 34 wherein the 
recurring record and the synthetic recurring record each 
contain a list of excluded date bearing instances, wherein the 
instruction for performing a comparison of the synthetic 
recurring record to the recurring record includes instructions 45 
for performing a comparison of the list of excluded date 
bearing instances of the recurring record with the list of 
excluded date bearing instances of the synthetic recurring 
record. 

38. The computer program of claim 37 wherein the 50 
instruction for completing synchronization includes instruc- 
tions for adding, modifying, or deleting the list of excluded 
date bearing instances of one of the recurring record and the 
synthetic recurring record. 

39. The computer program of claim 37 wherein the 55 
instruction for completing synchronization includes instruc- 
tions for adding, modifying, or deleting one of the synthetic 
recurring record and recurring record. 

40. The computer program of claim 37 wherein, following 
the instruction for completing synchronization, one of the 60 
synthetic recurring record and recurring record is fanned 
into a plurality of fanned non-recurring records excluding 
the instances in the list of excluded date bearing instances of 

a corresponding one of the synthetic recurring record and 
recurring record. 65 

41. The computer program of claim 34 further comprising 
instructions for storing a history file containing a record 
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representative of one of the recurring record and synthetic 
recurring record in a past synchronization. 

42. The computer program of claim 41 wherein the 
second database assigns a unique ID to each record, and 
wherein the computer program comprises: 

fanning one of the synthetic recurring record and the 
recurring record into a plurality of fanned non- 
recurring records; 

storing records in the history file representative of the 
plurality of fanned non-recurring records; 

storing in the history file the unique IDs assigned by the 
second database to the plurality of fanned non- 
recurring records; and 

recording linkages among the records representative of 
the plurality of non-recurring records and the record 
representative of one of the recurring record and syn- 
thetic recurring record. 

43. The computer program of claim 41 wherein the 
second database assigns unique IDs to each record, the 
history file further contains records representative of non- 
recurring records of the second database from a past syn- 
chronization and unique IDs assigned to the non-recurring 
records of the second database, and the instruction for 
processing a plurality of non-recurring records in the second 
database to generate a synthetic recurring record further 
comprises instructions for: 

performing a comparison of the unique IDs stored in the 
history file with unique IDs of the plurality of non- 
recurring records in the second database; and 

selecting a set of non-recurring records in the second 
database based on the comparison of the unique IDs 
and generating the synthetic recurring record using the 
set of non-recurring records. 

44. The computer program of claim 43 wherein the 
instruction for selecting a set of non-recurring records 
further comprises instructions for selecting a set of non- 
recurring records in the second database having unique IDs 
matching a set of the unique IDs stored in the history file. 

45. The computer program of claim 43 wherein one of the 
synthetic recurring record and the recurring record has an 
exclusion list and the instruction for selecting the set of 
non-recurring records comprises instructions for: 

selecting a set of records in the history file having unique 
IDs failing to match any of the unique IDs of non- 
recurring records in the second database; and 

adding, modifying, or deleting the exclusion list of at least 
one of the synthetic recurring record and the recurring 
record, using the set of records in the history file. 

46. The computer program of claim 41 further comprises 
performing a second comparison of one of the synthetic 
recurring record and the recurring record to the history file 
record representative of the recurring record or the synthetic 
recurring record in the past synchronization, and completing 
synchronization based on the outcome of the second com- 
parison. 

47. A computer implemented method of synchronizing at 
least a first and a second database, wherein records in the 
first and second databases include a key field, the method 
comprising: 

performing a first comparison of the content of the key 
field of the records of the first database with the content 
of the key field of the records of the second database; 

selecting a plurality of groups of records of the first and 
second databases based on the outcome of the first 
comparison; 
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performing a second comparison of the records in one of 
the plurality of groups of records to determine a cor- 
respondence between a record of the first database in 
the one of the plurality of groups and a record of the 
second database in the one of the plurality of groups; 5 

performing a third comparison of the records in the 
determined correspondence; and 

completing the synchronization based on the outcome of 
the third comparison. 

48. The method of claim 47, the method further comprises 10 
selecting the plurality of groups of records based on identity 

of the contents of Ihe key fields of the records of the first and 
second database. 

49. The method of claim 47 further comprising storing a 
history file containing history records representative of 15 
records of the first and second databases in a past 
synchronization, wherein performing a second comparison 
includes performing a comparison of the records in the one 

of the plurality of groups to the history records and wherein 
performing the third comparison includes comparing a cor- 20 
responding history record with the records in the determined 
correspondence. 

50. The method of claim 49 wherein the step of complet- 
ing synchronization further comprises: 

performing a third comparison of the records of the 
corresponding item group; and 

completing synchronization based on the third compari- 
son. 

51. The method of claim 47 wherein the key field is a date 30 
field. 

52. The method of claim 47 wherein the key field is a text 
field. 

53. A computer program, resident on a computer readable 
medium, for synchronizing at least a first and a second 35 
database, wherein records in the first and second databases 
include a key field, comprising instructions for: 

performing a first comparison of the content of the key 
field of the records of the first database with the content 
of the key field of the records of the second database; 
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selecting a plurality of groups of records of the first and 
second databases based on the outcome of the first 
comparison; 

performing a second comparison of the records in one of 
the plurality of groups of records to determine a cor- 
respondence between a record of the first database in 
the one of the plurality of groups and a record of the 
second database in the one of the plurality of groups; 

performing a third comparison of the records in the 
determined correspondence; and 

completing the synchronization based on the outcome of 
the third comparison. 

54. The computer program of claim 53, the computer 
program further comprises instructions for selecting the 
plurality of groups of records based on identity of the 
contents of the key fields of the records of the first and 
second database. 

55. The computer program of claim 53 further comprising 
instructions for storing a history file containing history 
records representative of records of the first and second 
databases in a past synchronization, wherein performing a 
second comparison includes performing a comparison of the 
records in the one of the plurality of groups to the history 
records and wherein performing the third comparison 
includes comparing a corresponding history record with the 
records in the determined correspondence. 

56. The computer program of claim 55 wherein the 
instruction for completing synchronization further com- 
prises instructions for: 

performing a third comparison of the records of the 
corresponding item group; and 

completing synchronization based on the third compari- 
son. 

57. The computer program of claim 53 wherein the key 
field is a date field. 

58. The computer program of claim 53 wherein the key 
field is a text field. 

***** 
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Cover page, [56] References Cited, OTHER PUBLICATIONS, the "Logical 
Connectivity" reference, "991" should be --1991-. 

FIG.l, "A_APPLICATION ( 7" should be -A_APPLICATION 17-. 

FIG. 3, at "104.", "rewritting" should be -rewriting-. 

FIG. 3, at "105", "form" should be -from- and "them" should be -then--. 

FIG. 4 A, at "150.", "prefernces" should be -preferences-. 

FIG. 4 A, at "152.", "Synchornization" should be -Synchronization-. 

FIG. 4B, at "167.", "Synchornization" should be -Synchronization-. 

FIG. 4B, at "173", "vlaues" should be -values-. 

FIG. 4B, at "175." "characterises" should be -characteristics-. 

FIG. 5A, at "200. 6", "sy" should be -synchronized-. 
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It is certified that error appears in the above-identified patent and that said Letters Patent is 
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FIG. 5 A, at "202.", "Synchrnization" should be -Synchronization--. 

FIG. 5A, at "203", "Synchrnization" should be -Synchronization--. 

FIG. 5 A, at "209.", "Synchrnization" should be -Synchronization-. 

FIG. 7, at "250.", "Field" should be -Field-. 

FIG. 8, at "302.", "Prevous" should be -Previous-. 

FIG. 12, at "502.", "beaing" should be -bearing-. 

FIG. 13, at "567.", "Previoius" should be -Previous-. 

FIG. 14, at "603.", "Dependant" should be -Dependent-. 

FIG. 15, at "631.", "Ifrecurring" should be -If recurring-. 

FIG. 25B, at "927.", "UPDDATE" should be -UPDATE-. 

FIG. 30, at "1052", "databasse" should be -database-. 

FIG. 30, at "1059.", delete the third occurrence of "a". 

FIG. 31 A, at "1161.", "Synchrnization" should be -Synchronization-. 
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Col. 21, line 58, "does" should be »do«. 
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Col. 4, line 52, "pseudocoe" should be -pseudocode-. 
Col. 10, line 48, "Nodule" should be -Module-. 
Col. 1 1, line 30, after "Map", delete the second period. 
Col. 13, line 46, "independant" should be -independent-. 
Col. 16, line 52, "use" should be -user-. 
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Title Page. 

[73] Assignee: "Puma Technology, Inc., Jose, Calif." should be ~ 
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